Various types of electronic transactions involve one party making a request for access to a resource from another party, which request may be granted based on an explicit permission or transactional conformance to stored permission-granting criteria. One type of permission-related transaction also involves a payment associated with the request (e.g., a purchase for a good or service). Customers may purchase goods or services directly from a merchant or vendor via a variety of electronic means, including in-person or in-store means such as credit cards, debit cards, or mobile-phone payment applications and remote or network-based means such as a web site or mobile-phone application. By authorizing payment upon presentation of the transaction details, the customer gives explicit permission to a payment entity to pay the merchant in accordance with the presented terms.
Increasingly, the transactional relationship between buyer and seller is being attenuated by the emergence of third-party entities that serve as aggregators or portals for a plurality of merchants, vendors, or other entities. A customer typically interacts with the third-party entity via a web site or software application, and the third-party entity displays the goods or services offered by the aggregated merchants. The customer submits a request or order to the third-party entity, which relays the request to the appropriate merchant. If the merchant accepts, the third-party entity so informs the customer. The third-party entity may also act as a payment processor and interact with a funding source associated with the customer and submit payment to the merchant. In such transactional contexts, the additional involved parties increase the number of permissions required to actually complete the sale—for example, from customer to aggregator to vendor for payment, from a credit-card processor to the vendor for reimbursement, and from vendor to aggregator for order confirmation.
FIG. 1 illustrates an example environment 100 of such a transaction. A customer 102 visits a web page of an online food-services vendor 104, which displays the menu items of a plurality of restaurants 108. The customer 102 selects a food item for pick-up or delivery, and the vendor 104 communicates with a restaurant 108 associated with the food item to thereby fulfill the request of the customer 102. Payment for the item is received from a credit-card server 106 and supplied to the restaurant 108. FIG. 2 illustrates a more general example 200 of this sort of transaction, in which a requester 202 seeking access to a resource 204 communicates with a request relayer 206 in order to have a request granted by a request manager 208. Following permission from the request manager 208, the request relayer 206 communicates with the resource 204 in order to accord access to the requester 202 in accordance with the accepted terms of the request.
Aggregation may be attractive for customers because they need interact with only one entity, the request relayer 206, in order to access goods or services from a number of different request managers 208 (e.g., restaurants 108 in the above example). Request managers 208 may benefit from this type of transaction because, for example, they need not maintain electronic infrastructure, such as web pages and financial-transaction software, which instead is created and maintained by the request relayer 206. Outside the sales context, request managers may find it convenient to set up computationally resolvable criteria for permissions management and allow a third party to manage the mechanics of access. For example, the resource may be a collection of stock photographs that are licensed on standard terms depending on the requester's intended use, or even sensitive financial information that, for example, a merchant must make repeatedly accessible to actual or prospective sources of financing. In all of these cases, a firm's ability to expand its market audience (via an aggregator) or outsource permissions management (via a request handler) can be highly beneficial.
Other aspects of the transaction environment 200 are less advantageous. Because a request manager 208 does not interact directly with a requester 202, the request manager 208 cannot collect data about the requester 202, such as demographic data, location data, or purchase-history data. The request manager 208 is further limited in its inability to extend promotions, coupons, or offers to the requester 202. And while the network and/or financial infrastructure burden for request processing is at least partially lifted from the request manager 208, it is merely shifted to the request relayer 206, which must bear the burden of mediating access to the resource 204, e.g., creating and maintaining payment-processing functions in a purchase context. A need therefore exists for an improved system and method for facilitating permissions management in the context of electronic payments and other transactions.